home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 321 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.8 KB
  1. From: Eugene Lazutkin <eugene@int.com>
  2. Message-ID: <01BAF54A.5F4D5AC0@Cust46.Max3.Dallas.TX.MS.UU.NET>
  3. X-Original-Date: Wed, 7 Feb 1996 10:52:21 -0600
  4. Path: in2.uu.net!bounce-back
  5. Date: 08 Feb 96 10:51:24 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Organization: -
  8. Newsgroups: comp.std.c++
  9. Subject: RE:  Cleaning auto_ptr copy semantics.
  10. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  11.     iQBEAgUBMRnWFOEDnX0m9pzZAQH/YwF44D5XzqXYxO5Zi9iURKzIkJen/qr9ZKlB
  12.     hunpwbnH/LG1DNSg2yJbkjOvOujaOd0=
  13.     =UNx1
  14.  
  15. On     Sunday, February 04, 1996 6:09 PM, 
  16. John Max Skaller <maxtal@suphys.physics.su.oz.au> wrote:
  17. > Eugene Lazutkin wrote:
  18. > [auto_ptr]
  19. > 
  20. > > It's good if you are going to create a STL
  21. > > container of auto_ptr's.  
  22. > 
  23. >     EGADS! NEVER DO THIS!!!!
  24. > 
  25. >     The following will CRASH FOR SURE:
  26. > 
  27. >     void f(vector<auto_ptr<X> >){}
  28. >     vector<auto_ptr<X> > vx; vx.push_front(new X);
  29.  
  30. You're right.  push_front() for vector<> is not good idea! :-)
  31.  
  32. >     f(vx);
  33.  
  34. This is a very time-consuming operation. You should use it if it 
  35. is really essential for you.
  36.  
  37. >     vx[0]; // CRASH
  38.  
  39. Right.  I have a shorter example to demonstrate the same behavior.
  40. It doesn't use STL at all!
  41.  
  42.     // declarations
  43.     typedef    auto_ptr<T>    aptr;
  44.     void    f( aptr );
  45.  
  46.     // example
  47.     aptr    p( new T );
  48.     f( p );
  49.     *p;    // CRASH
  50.  
  51. What's your point?  I agree with your that non-reference counting
  52. (or non-garbage collecting) pointers are dangerous.  I mean both
  53. C-style old-fashioned pointers and current auto_ptrs.  But you can
  54. write a program which doesn't violate certain restrictions.
  55.  
  56. To me auto_ptr is useful under certain circumstances. It's better 
  57. than nothing. At least in this case I can control the life of the 
  58. pointed object (if I write my program correctly).  Garbage collection
  59. doesn't guarantee anything.
  60.  
  61. It's sad that reference counting was rejected by the committee.
  62. Maybe it was a better choice.
  63.  
  64. > Copying the container transfers ownership to the NEW container.
  65. > You must NOT use FIFO/block structure here: if the new
  66. > container is destroyed before the old one, all the auto_ptrs
  67. > in the old container dangle.
  68. > 
  69. > Even worse, if you have an input iterator onto the container
  70. > which returns an rvalue, dereferencing it steals ownership
  71. > from the container by creating a copy -- the destruction
  72. > of which will delete the object, leaving the container's
  73. > auto_ptr dangling. 
  74.  
  75. You have the same problems without any containers.
  76.  
  77. > [Correct use of the idiom requires the newest copy of
  78. > an auto_ptr outlive use of older ones. This is often
  79. > achieved by assigning the newest value back to the object
  80. > it was copied from.]
  81.  
  82. Eugene Lazutkin
  83. eugene@int.com
  84. ---
  85. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  86.   Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  87.   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  88.